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(54) Security module 

(57) A security module for use in an 
electronic funds transfer terminal is 
contained in a tamper-resistant 
housing. The module has a PIN pad 
and is designed to encrypt secret 
data, such as users personal Identity 
numbers (PlNs), so that other 
terminal processes cannot gain 
access to it. The encryption 
functions are carried out in a security 
controller (Fig. 5) which includes its 
own microprocessor and 
encryption/decryption unit. 
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SPECIFICATION 

Security module for and electric funds 
transfer system 

5 

The present invention relates to a security 
module for an electronic funds transfer system 
(EFT), and particularly to such a module that is 
to be used at a point of sale terminal in an 
10 EFT network designed to connect a plurality 
of disparate retailer's terminals through a 
switched telecommunications network to a 
plurality of funds holder's data processing 
centres. 

15 In an EFT system in which many retailers 
having separate and different contractual rela- 
tionships with card issuing funds holders and 
controllers it is necessary for the point of sale 
terminal to be able to respond uniquely to the 

20 different cards that it receives, and reads, 
from the card holding users. It is also neces- 
sary for the card holders to have confidence 
in the retailer's terminals and not be con- 
cerned that the retailer is trapping secret infor- 

25 mation, such as personal identification num- 
bers (PINs), for later fraudulent use. 

One system that has been proposed to deal 
with these problems is described in our UK 
patent Applications Nos. 83/24916 and 

30 83/24917. This system relies on the use of 
the so-called smart card in which the security 
operations, encryption and decryption of PlNs 
etc., are computed in the card holder's per- 
sonal portable microprocessor mounted in the 

35 card. This use of personal portable micropro- 
cessors is obviously a very flexible and secure 
system, but compared with the cost of mag- 
netic stripe cards and considering the numbers 
involved the cost of the smart card is proving 

40 to be a hurdle to its widespread acceptance. 
It is an object of the present invention to 
provide a technical solution to the problems of 
terminal flexibility and security confidence for 
use in an EFT/POS system in which the users 

45 have issued cards containing information held 
on a magnetic stripe and who also have a 
secret personal identity number, which may, 
or may not, also be stored on the magnetic 
stripe. 

50 In broad terms, the present invention pro- 
vides a technical solution to the problems 
posed above by including with each retail ter- 
minal a tamper-resistant security module. The 
security module can be physically included in 

55 the terminal housing or attached by a short 
cable through suitable input/output ports. Each 
module includes a microprocessor that is con- 
trolled to perform different message formatt- 
ing routines depending upon the type and ori- 

60 gin of a magnetic stripe card input through a 
magnetic stripe reader. The module also has 
incorporated within its structure a PIN pad fof 
a user to enter security information such ias a ; 
PIN. 

65 According to the invention there is provided 
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a security module, for authenticating messages 
having a plurality of different formats and 
cryptographic authenticators, contained in a 
tamper-proof housing and including two data 
70 input devices, a display unit, at least one in- 
put/ output port for connecting the module to 
an external processor and a security control* 
ler, characterised in that the security controller 
includes: at least one read only memory which 
75 stores a state table and a module master en- 
cryption key; a control logic unit including a 
microprocessor and a control store which 
stores a plurality of different control function 
routines invoked by different entries In the 
80 state table; means to generate different en- 
cryption keys dependant upon a particular 
control function and a derivative of the module 
master key; and means to perform encryption 
and decryption operations on messages 
85 transmitted to and from the module using 
keys transmitted to the module encrypted un- 
der one of a number of derivatives of the 
module master key, whereby data input to the 
module at the first of the two data Input de- 
90 vices is used to determine the control function 
routine that the module is to perform and the 
encryption key used to encode data input at 
the second data input device. 
According to a second aspect of the inven- 
95 tion there is also provided a method of using 
a security module in an electronic funds trans- 
fer system terminal to secure secret data from 
other terminal processes, and in which the se- 
curity module has a data input device for re- 
100 ceiving secret data comprising the steps of: 
storing in the module a set of master keys 
each encrypted under a respective function 
key; transmitting to the security module from 
a terminal process a function request and a 
105 function key; decoding the appropriate master 
key using the function key; and encoding the 
secret data using the decoded master key in 
the security module and transmitting the en- 
coded data to the terminal processes. 
110 In order that the invention may be fully un- 
derstood a preferred embodiment thereof will 
now be described with reference to the ac- 
companying drawings in which: 
Figure 1 is a schematic diagram of a portion 
115 of an EFT/POS network. 

Figure 2 is a schematic diagram showing 
the major components of a security module. 

Figure 3 illustrates the connection between 
the security module, a POS terminal and a 
120 remote application processor. 

Figure 4 shows how the security module is 
shared between two applications. 

Figures 5, 6, and 7 illustrate the construc- 
tion and methods of operating the security 
125 module. 

Figures 8, 9, 10 and 11 are flow charts 
illustrating the operation of the security mo- 
dule. 

• - Referring now more particularly to the draw- 
130 ings, in order to provide an understanding of 
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the background of the invention there is ini- 
tially a general discussion on the design of 
EFT networks. 
There are many possible designs and ways 
5 of defining the equipment at the point-of-sale 
in EFTPOS. Most of the designs can be char- 
acterised by the fact that the EFTPOS "termi- 
ner is a complete system, that is, it is a 
complete add-on to the POS equipment, for 

10 the purpose of EFTPOS. 

Viewed from the Access Controller (AC) the 
"terminal" is seen as a system with which 
the AC has a communications session. In 
Open System Interface (OSI) terms, the AC 

15 and terminal are two systems with one or 
two networks (Telecommunication local net- 
work and the In-Store network). 

Figure 1 shows a retailers connection to an 
EFT network. An in-store network 10 has 

20 several EFT/POS terminals connected to it. 
Each unit comprises a retailers point of sale 
terminal 1 1 and an associated electronic funds 
transfer terminal 12. The in-store net 10 is 
provided to link the terminals 1 1 and 12 and 

25 the combined POS equipment to the local net- 
work 14 through a network termination point 
13. The local telecommunication network 14 
has a connection to an access controller (AC) 
15. 

30 The network termination point 13 is the re- 
tailers connection point to the local network 
13, the "phone jack". The combination of 1 1 
and 12 provide the full facilities necessary to 
perform EFTPOS transactions. 

35 The EFTPOS "Terminal" in the main will be 
a distinctive secure unit with a magnetic stripe 
reader, pin-pad, display, security processor 
and transaction processor. The terminal is re- 
sponsible for the whole of the transaction, it 

40 includes the terminal application control func- 
tion which performs EFTPOS in conjunction 
with the AC. It is also necessary for the ter- 
minal to support individually managed keys for 
any card issuer who wants them. 

45 Previously the terminal has been considered 
to be responsible for the EFTPOS transaction 
in combination with other retailer equipment 
such as cashier display for total value input 
and most, importantly, for communication to 

50 the telecommunication network and transac- 
tion record printing. 

The terminal described below appears simi- 
lar, but has actually changed significantly. In 
this view, the EFTPOS "terminal" as seen 

55 from the EFTPOS network is an application 
running in the retailers equipment making use 
of a security controller in a secure PIN pad 
(SPP) or security module. 
The security module is available to this ap- 

60 plication to provide an authentication service, 
its function is to provide a service which al- 
lows the card issuer to be satisfied that the 
correct procedures have been adhered to. 
The basic component parts of the security 

65 module are shown in Figure 2. The module 20 



includes a magnetic stripe reader 21 con- 
nected to a security controller 22. A liquid 
crystal display is also connected to the con- 
troller. Typically the display will have two lines 
70 of eighteen characters. A pin-pad 24 is con- 
nected to the controller and coded function 
requests are received on a line 25 from an 
application process running in the main termi- 
nal processor. A data bus 26 connects the 
75 security controller to the application process | 
which can also have a direct connection to 
the display. 

It may optionally contain a distributed por- 
tion of the retailer equipment application run- 
80 ning in a processor with memory. 

The security controller 22 is the only stan- 
dard component and must be supplied by an 
authorised source. It must be connected to 
the pin-pad 24 and magnetic stripe reader 21 
85 in a manner which satisfies the security re- 
quirements of EFTPOS, and the security mo- 
dule must be built to conform to the security 
and physical standards of EFTPOS. 
Within the retailers equipment (optionally 
90 within the security module) the terminal sys- 
tem includes a processor {or distributed appli- 
cation on more than one processor). The ap- 
plication supports the management of crypto- 
graphic keys and their storage as defined by 
95 EFTPOS. 

The security controller 22 is a special pur- 
pose cryptographic unit. It contains two 
values — an identification number (SCID) and a 
master key (SCMK). 
100 The SCID is recorded in the security control- 
ler during the manufacture process, the SCMK 
is Installed subsequent to manufacture but 
prior to first installation onto the network by a 
secure means ^specified by EFTPOS. A security 
105 controller is regarded as authentic if it pro- 
duces cryptograms which prove that it con- 
tains a valid (SCID, SCMK) pair* The applica- 
tion, processor (or processors) will hold keys 
encrypted under variants of SCMK. The secu- 
1 10 rity controller provides a set of functions 

which will not disclose SCMK. SCMK is held 
in a secure manner and will be destroyed as a 
result of any action that might allow SCMK to 
be discovered; 
1 15 The identification SCID is not secret, in fact, • 
it may be stamped or written onto the secu- 
rity module to aid the inventory and mainte- 
nance processes. ' 
The application may be allowed direct con- 
120 trol of the display 23 and the security control- 
ler communicates with the application process, 
via an internal bus. This communication may 
be extended to a distant processor, or part of 
the application may be distributed to a proces- 
125 sor within the security module, communicating 
between parts' of the system by any suitable 
means. 

A set of functions communicated over the 
SC buses are: 
130 D — Reset 
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1 — Read MSR The SC waits for a card to 
be read, strips out non-transmitted card data 
(NCD), stores it in a register and sends the 
transmitted card data (TCD) as a response. 
5 Possible responses: 

1 — Card read + TCD 

2 — Mis-read 

2 — Provide authorisation token 

3 — Start message authentication check 

10 (MAC) calculation (key provided under variant 
of SCMK) 

4 — MAC input data 

5 — Finish MAC calculation — return MAC 

6 — Given encrypted CIRN token + key 
15 7— Check PIN 

Input authentication token + key 
Result indication + confirmation token 
Result = 1 PIN ok, -h token 
2 PIN failure 

20 The security controller will refuse to perform 
this function more than three times, after this 
it will require a reset. 
8 — Give next key 
Input key under variant of SCMK 
25 Output new key under variant of SCMK 
The security module contains a record of 
the function number of the most recent use. It 
will respond correctly only if the current func- 
tion request is the next in an allowable se- 
30 quence. 

Failure to conform to the correct sequence 
will render the security module Inactive, a 
state which can only be changed by a 0 — Re- 
set function. 

35 Since the security controller has access to 
important transaction data, and it generates 
MAC'S, there is a wide range of possibilities 
for the algorithm for generating next key in 
function at step 8. 

40 The security scheme may call for the secu- 
rity controller to maintain a synchronised time 
reference value. If this is the case, then there 
will need to be a further function to set the 
time reference and a further key TRK in the 

45 security controller to authenticate any value 
set into a time register (TR), The security con- 
troller could return the TR on function 0 (re- 
set), or yet a further function call. 
The security module Is used by the applica- 

50 tion in a manner similar to the use of a set of 
support subroutines, if the application uses 
the correct sequence of calls (functions) pro- 
viding the correct data and keys (encrypted 
under SCMK variants) then the result will be 

55 tokens and MAC'S which will collectively allow 
the card issuer host to authenticate the secu- 
rity module, the card and card holder. If incor- 
rectly used, the authentication will fail, and the 
security module cannot be mis-used in a man- 

60 ner which will subvert the system without ac- 
cess to considerable amounts of other data 
and collusion of several parties in different lo- 
cations. 

This removes the following responsibilities, 
65 which are normally considered to be functions 



of an EFTPOS terminal, from the security mo- 
dule: 

Transaction management. 

70 The security module provides services to 
allow a remote host to be satisfied that a 
procedure has been followed. This Is achieved 
because of the existence of tokens (MAC's 
and cryptograms) which can only be produced 

75 by a valid security module, together with se- 
cret information, which has been used in a 
correct manner. 

Recovery responsibility 
80 The previously assigned recovery responsi- 
bility of the EFTPOS terminal can now be as- 
signed to retailers equipment and applications 
code. 

85 Key management 

The security module need only have one 
key (or possibly a small number as Indicated 
by a need for down-loaded information such 
as synchronised time references). This (or 

90 these) keys will be Installed by a fixed key 
loading procedure. In EFTPOS this could be a 
central facility. 

Alternative uses of the security module 
95 The security module finds other uses in net- 
works that require cryptographic transmission 
of information and further examples are now 
given as they would apply to an EFTPOS net- 
work. 

.100 First the use of the security module as an 
authentication device shared by several appli- 
cations and secondly the extension of the se- 
curity module by the addition of a 'state vari- 
able' which allows its use in alternative and 

105 exclusive cryptographic schemes. 

1) Use by Multiple Applications 

The partitioning of function is illustrated in 
Figure 3 which shows the security module 20 

110 connected over lines 25 and 26 to interface A 
of a terminal 27 which contains local applica- 
tion processes and at least a set of cryptogra- 
phic keys 28. The terminal is connected 
through interface B to a processor of remote 

1 1 5 application processes 29 through a network 
route indicated as 30. 

Interface 6 is precisely the network appear- 
ance of an EFTPOS terminal. Interface A Is 
used to communicate the data which requests 

120 the security module to perform its available 
functions and to return the results to the ap- 
plication. 

Since the function of the security module is 
to provide data and tokens which allow a re- 

125 mote application to validate the procedures 
employed at the local site,* It follows that one 
security module can be used by any number 
of local applications, and in turn any number 
of remote: applications for the similar pur- 

130 poses. 
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The security module represents a serially re- 
usable resource. It can only be used success- 
fully for a complete legal sequence by one 
application at any time. 

5 The keys used by the application process 
will be held at the local processor encrypted 
under variants of SCMK, the security module's 
security controller's master key. 
Figure 4 shows the security module being 

10 made available to two local applications A and 
B. The security module 20 is connected to a 
terminal 27 which is running two applications 
A and E. Three remote processors are shown 
31,32 and 33 connected through the switch 

15 30. The security module 20 is used to au- 
thenticate procedures and data for the remote 
hosts 31, 32 and 33 using a combination of 
applications A and E. Note: The keys held at 
the remote hosts will be encrypted under the 

20 appropriate host master keys. 

2) Use of Alternative Cryptographic Schemes 
The security module as described above is 
defined as enforcing a single procedure. In 
25 particular, it withholds data read from the card 
(or other means) which will be retained as 
secret from the local application and any other 
components between the security module and 
the remote host. Primarily for use in personal 
30 key (KP) cryptography where KP must be con- 
structed using that secret. 

To extend this scheme, it Is necessary to 
allow the security module to handle several 
procedures, ie, several sequences of function 
35 calls. As an example consider the use of the 
SC in a second scheme which requires that 
the entire track 2 of the card be transmitted 
(encrypted). 
To achieve this extension, the security mo- 
40 dule must contain a 'state variable'. This 
represents the history of the sequence of 
functions performed since the last reset oper- 
ation. The sequences now contain points at 
which the possible next function is one of a 
45 set of functions rather than one function, a 
branch point. 

The state of the terminal takes a value de- 
pending upon the function requested at any 
branch point. Thus, the next allowable func- 
50 tion is decided by a combination of the last 
function requested and the value of the state 
variable. The state variable is updated to 
represent the new state once the function is 
requested. As before, any deviation from the 
55 prescribed sequence will result in a security 
module becoming inactive, ie, the previous de- 
scription has a single state. 

To demonstrate this, consider the list of 
functions described above. 
60 Following a function 1, the application may 
decide that the card must be handled without 
personal key cryptographies. It wishes to read 
all of track 2. Thus, a new function — say 
100, may follow function 1. 
65 100— Read all card data. Input KEY en- 



crypted under variant 

variant of SCMK. Return all of card data (in- 
cluding NCD) 
encrypted under KEY. 

70 The state variable will take a different value 
if function 100 follows function 1, than it 
would if function 2 follows function 1 . If the 
function following 1 is 100 then the security 
controller will prohibit the use of functions 2, 

75 3, 4, etc. This allows alternative exclusive 
schemes to be implemented. 

In particular, subject to secure design of the 
functions and states, it allows any schemes to 
be implemented, including conflicting schemes 

80 such as those which require track 2 of a card 
to be partially secret together with those that 
require the whole of track 2 to be made avail- 
able. 

85 Master Key Vanar\ts. 

The use of SCMK variants must be selected, 
based on the requested function and state 
variable to enforce partitioned use of security 
controller functions in the security module in 

90 alternative schemes. Thus, each scheme must 
use selected key variants. 

The number of the variant to be used can 
be selected from a table based on the current 
state and the requested function. The key 

95 used in the operation can be formed by deci- 
phering the selected variant number using 
SCMK. This means that keys in the application 
will be held in the following fornri: 

100 E ( D ( SCMK, variant no.), KEY) 

Using the notation E ( key, data) means 
data enciphered under key and D (key, cipher- 
text) means the result of deciphering cipher- 

105 text using key. 

This approach would allow schemes for 
separation of function by intended destination. 
Such a scheme is shown in Figs 6 and 7. The - 
security controller ID and destination data ex- 

110 tracted from the card magnetic stripe track 2 
are used to provide a separation of keys. 

The security can be enhanced if the key 
variant is produced by a one-way function in 
place of the simple decipher operation. 

1 1 5 The variant number key is loaded at the 
same time as the state table |ie. at manufac- 
ture or installation of keys). 

This scheme can be further enhanced by 
selecting further information from a further ta- 

120 ble to generate the destination information 
prior to producing the master-key variant as 
above. This latter table can be down-loaded 
to the security controller periodically (eg. at 
start of day). As wi.h other possible down- 

125 loaded information the table load operation re- 
quires authentication using additional keys. 

Security Module 
The internal components of the security mo- 
1 30 dule will now be describe with reference to 
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Figures 5, 6 and 7. The security controller 22 
(Figure 2) is shown in more detail in Figure 5 
and comprises a state table 51, which in a 
preferred embodiment is Implemented in a 

5 read only memory (ROM) chip, the address is 
formed by concatenating outputs from three 
registers. The registers are shown separately 
as State 52, Last Function 53 and Function 
54, but in practice are parts of a random ac- 

10 cess store (RAS). 

The state register 52 holds a value which 
represents the current state of the security 
controller. The contents of the state register 
52 are also available to be tested by the con- 

15 trol unit 56. One value of the state register 
contents, for example zero, is designated to 
indicate that the unit is inactive following an 
invalid function request sequence. The control 
unit only permits a RESET function request 

20 when the inactive state is detected. The value 
in the last function register 53 represents the 
function performed on the previous cycle of 
operations of the security module. The value 
in the function register 54 represents the cur- 

25 rent function to be performed. The function 
register 54 receives its input from the applica- 
tion process on line 25 (Figure 2) and has a 
direct connection to the last function register 
53. The state register 52 receives its input 

30 directly from the state table 5 1 . 

The output of the state table is split into 
two fields, one field is entered into the state 
register and the other is used as the address 
of a master key table 55. The. master key 

35 table provides one of a set of master key 
values to a user key decipher unit 57. The 
value depends upon the function currently be- 
ing performed and the values entered into the 
state table from the three registers. The mas- 

40 ter key table could be part of the state table 
ROM but it is preferred that the values are 
generated as functions of a single key. Em- 
bodiments implementing the preferred system 
are described below with reference to Figs 6 

45 and 7. 

The operation cycles for each function per- 
formed by the security controller are con- 
trolled by a control logic unit 56. The control 
unit interprets the function request and pro- 

50 vides the appropriate timing and control sig- 
nals to route data signals between the other 
components. The unit comprises a micropro- 
cessor and a ROM containing the control rou- 
tines necessary to provide the required gating 

55 and control signals. Each routine is associated 
with a particular function and will result in a 
different encoding and decoding operation in 
the controller. 
The user key decipher unit 57 deciphers the 

60 user key received from the data bus 26 

through a buffer store 60 under the control of 
uriit 56. The decipher key is obtained from 
the master key table 55. The user key deci- 
pher unit implements the decipher function of 

65 the Data Encryption Standard (DES). 



A working register 58 is loaded with a key 
produced by the user key decipher unit 57. 
The working register 58 may also be loaded 
from the data bus 26 under the control of unit 
70 56 whenever a function routine requires the 
generation of composite keys, for example a 
key constnjcted from card input data, other 
user data and a variation of the master key. 
The value loaded into the working register 
75 represents a key in the clear and is not 
transmitted out of the security controller. In 
order to ensure that the clear key exists for 
the minimum necessary time, at the end of 
each cycle the working register is loaded with 
80 a string of zeros. 

An encryption unit 59 performs the primitive 
encryption operations needed for the operation 
of the requested function. This unit imple- 
ments the DES. The keys for the encryption 
85 are received from the working register 58, 
Output from the encryption unit 59 is fed to a 
buffer store 60 which temporarily holds alt 
data and intermediate results during the pro- 
cessing required by the requested function. 
90 In operation the security controller reads a 
value representing a function request into the 
function register 54. Each function is per- 
formed by executing a cycle of operations. 
The cycle consists of standard initial and final 
95 sequences of operations with a main sequence 
selected on the basis of the requested func- 
tion. The initial and final sequences are illus- 
trated in the flow-charts of Figures 8 and 9. 
The reset function is illustrated in Figure 10. 
100 The sequence for the function for reading the 
data input at the magnetic stripe readed is 
illustrated in Figure 1 1 , this is given as an 
example of other function sequences that the 
control unit follows. 
105 In the following description of the operation 
of the security controller the state register 
contents wiil indicate a value of zero when an 
invalid function sequence is requested, this in- 
dicates an inactive state of the module. 
110 The steps of the initial sequence (Figure 8) 
are: 

Step 1 (81): Determine whether the function 
request 0, if so them go to the Reset 
1 15 routine (Figure 10), if not then proceed to 
next step. 

Step 2 (82): Determine whether the value in 
the state register 52 = 0, if so then go to 
120 step 3 (83), if not then proceed to step 4 
(84). 

Step 3 (83): Provide an output failure indica- 
tion to the terminal processes and to the dis- 
125 play unit. Finish the routine. 

Step 4 (84): Strobe the function register. 

Step 5 (85): Strobe the state register. 
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Step 6 (86): Determine whether the value in 
the state register 52 « 0, if so then go to 
step 3 (83), if not then proceed to select the 
sequence indicated by the value in the state 
5 register. 

The steps of the final sequence (Figure 9) are 
as follows; 

10 Step 1 (87): Strobe the last function register 
to preserve the value of the current function 
request. 

Step 2 (88): Set the worlcing register to all 
15 zero contents, to erase the clear version of 
the encryption key used for the current func- 
tion. End the function. 

The reset function consists of one step (89) 
20 and that is to strobe the function register, and 
then go to the final sequence. 

The steps for Function 1 (Read the magnetic 
stripe reader) are shown in Figure 1 1 and are 
as follows: 

25 

Step 1 (90): Wait for a card to be read. 

Step 2 (91): Read the card, if the read data is 
satisfactory then go to step 4. if not then go 
30 to step 3. 

Step 3 (92): Provide an output failure indica- 
tion to the terminal processes and to the dis- 
play unit. Finish the routine. 

35 

Step 4 (93): Determine the card data to be 
transmitted (TCD). For example the TCD may 
be defined as those digits from card traclc 2 
between start sentinel and field separator. 

40 

Step 5 (94): Generate an output indication that 
the previous step has been carried out suc- 
cessfully and transmit it to the terminal pro- 
cesses. 

45 

Step 6 (95): Output the TCD to the terminal 
on data bus 26, then go to the final sequence 
routine (Figure 9). 

50 This sequence will have a series of sub- 
routines at step 4 each providing a different 
set of TCD and chosen on the card issuers 
identity read at step 2. 
Other function routines follow the same gen- 

55 eral pattern of the sequences described 
above. 

CLAIMS 

1. A security module, for authenticating 
60 messages having a plurality of different for- 
mats and cryptographic authenticators, con- 
tained in a tamper-resistant housing and in- 
cluding two data input devices, a display unit, 
at least one input/output port for connecting 
65 the module to an external processor and a 



security controller, characterised in that the 
security controller includes: 

at least one read only memory which stores 
a state table and a module master encryption 
70 key; 

a control logic unit including a microproces- 
sor and a control store which stores a plural- 
ity of different control function routines in- 
voked by different entries in the state table; 
75 means to generate different encryption keys 
dependent upon a particular control function 
and a derivative of the module master key; 
and 

means to perform encryption and decryption 
80 operations on messages transmitted to and 
from the module using keys transmitted to the 
module encrypted under one of a number of 
derivatives of the module master key; 
whereby data input to the module at the first 
85 of the two data input devices is used to de- 
termine the control function routine that the 
module is to perform and the encryption key 
used to encode data input at the second data 
input device. 

90 2. A security module as claimed in claim 1 
further characterised in the the security con- 
troller includes at least three registers: a func- 
tion register, a last function register and a 
state register and that the state table is ad- 
95 dressed by using a combination of the cun-ent 
entries in the three registers. 

3. A security module as claimed in claim 1 
or claim 2 further characterised in that the 
security controller includes a buffer store and 

100 data input from the two data input devices are 
stored in the buffer store before being en- 
coded and in which the first data input device 
is a magnetic stripe reader and the second 
data input device is a PIN pad. 

105 4. A security module as claimed in any one 
of claims 1 , 2 or 3 including means to detect 
when an invalid sequence of functions has 
been requested for the module to perform and 
to invoke an abort routine when an invalid 

1 10 sequence is detected. 

5. A method of using a security module in 
an electronic funds transfer system terminal to 
secure secret data from other terminal proces- 
ses,and in which the security module has a 

1 15 data input device for receiving secret data 
comprising the steps of: 

storing in the module a set of master keys 
each encrypted under a respective function 
key; 

1 20 transmitting to the security module from a 
terminal process a function request and a 
function key; 

decoding the appropriate master key using 
the function key; and 

1 25 encoding the secret data using the decoded 
master key in the security module and 
transmitting the encoded data to the terminal 
processes. 

6. A method as claimed in claim 5 in which 
1 30 a single master key is stored in the security 
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module and derivative master keys are gener- 
ated from the master key using predetermined 
function request data received from the termi- 
nal processes. 
5 7. A method as claimed in claim 5 or claim 
6 in which the terminal has at least a second 
data input device for receiving data from a 
user and the operable terminal process is de- 
pendant data input at the second data input 
10 device. 
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